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Abstract 


The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol 
conceived for the description and negotiation of a telepresence session. The design of the CLUE 
protocol takes into account the requirements and the framework defined within the IETF CLUE 
Working Group. A companion document, RFC 8848, delves into CLUE signaling details as well as 
the SIP / Session Description Protocol (SDP) session establishment phase. CLUE messages flow 
over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" 
stands for "Stream Control Transmission Protocol".) Message details, together with the behavior 
of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This document is a 
product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for publication by the Internet 
Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for 
any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc8847. 
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1. Introduction 


The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol 
used by two CLUE Participants to enhance the experience of a multimedia telepresence session. 
The main goals of the CLUE protocol are as follows: 


1. enabling a Media Provider (MP) to properly announce its current telepresence capabilities to 
a Media Consumer (MC) in terms of available media captures, groups of encodings, 
simultaneity constraints, and other information defined in [RFC8845]. 


2. enabling an MC to request the desired multimedia streams from the offering MP. 


CLUE-capable endpoints are connected by means of the CLUE data channel -- an SCTP-over-DTLS 
channel that is opened and established as described in [RFC8848] and [RFC8850]. ("SCTP" stands 
for "Stream Control Transmission Protocol".) CLUE protocol messages flowing over such a 
channel are detailed in this document, both syntactically and semantically. 
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In Section 4, we provide a general overview of the CLUE protocol. CLUE protocol messages are 
detailed in Section 5. The CLUE protocol state machines are introduced in Section 6. Versioning 
and extensions are discussed in Sections 7 and 8, respectively. The XML schema [W3C.REC- 
xml-20081126] defining the CLUE messages is provided in Section 9. 


2. Terminology 


This document refers to terminology that is also used in [RFC8845] and [RFC7262]. For 
convenience, we list those terms below. The definition of "CLUE Participant", as also listed below, 
originates from this document. 


Capture Encoding: A specific encoding of a Media Capture, to be sent via RTP [RFC3550]. 


CLUE Participant (CP): An entity able to use the CLUE protocol within a telepresence session. It 
can be an endpoint or an MCU (Multipoint Control Unit) able to use the CLUE protocol. 


CLUE-capable device: A device that (1) supports the CLUE data channel [RFC8850], the CLUE 
protocol, and the principles of CLUE negotiation and (2) seeks CLUE-enabled calls. 


Endpoint: A CLUE-capable device that is the logical point of final termination through receiving, 
decoding, and rendering, and/or initiation through the capturing, encoding, and sending of 
media streams. An endpoint consists of one or more physical devices that source and sink 
media streams, and exactly one participant (as described in [RFC4353]) that, in turn, includes 
exactly one user agent [RFC3261]. Endpoints can be anything from multiscreen/multicamera 
rooms to handheld devices. 


Multipoint Control Unit (MCU): A CLUE-capable device that connects two or more endpoints 
together into one single multimedia conference [RFC7667]. An MCU includes a mixer (as 
defined in [RFC4353]), without the requirement per [RFC4353] to send media to each 
participant. 


Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, 
video, or timed text. 


Media Capture: A source of media -- for example, from one or more Capture Devices or 
constructed from other Media streams. 


Media Consumer (MC): A CP (i.e., an Endpoint or an MCU) able to receive Capture Encodings. 
Media Provider (MP): A CP (i.e.,an Endpoint or an MCU) able to send Capture Encodings. 


Stream: A Capture Encoding sent from an MP to an MC via RTP [RFC3550]. 
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3. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


4. Overview of the CLUE Protocol 


The CLUE protocol is conceived to enable CLUE telepresence sessions. It is designed to address 
Session Description Protocol (SDP) limitations in terms of the description of some information 
about the multimedia streams that are involved in a real-time multimedia conference. Indeed, by 
simply using SDP, it is not possible to convey information about the features of the flowing 
multimedia streams that are needed to enable a "being there" rendering experience. Such 
information is contained in the CLUE framework document [RFC8845] and formally defined and 
described in the CLUE data model document [RFC8846]. The CLUE protocol represents the 
mechanism for the exchange of telepresence information between CPs. It mainly provides the 
messages to enable an MP to advertise its telepresence capabilities and to enable an MC to select 
the desired telepresence options. 


The CLUE protocol, as defined in this document and further described below, is a stateful client- 
server XML-based application protocol. CLUE protocol messages flow on a reliable and ordered 
SCTP-over-DTLS transport channel connecting two CPs. Messages carry information taken from 
the XML-based CLUE data model [RFC8846]. Three main communication phases can be 
identified: 


Establishment of the CLUE data channel: 
In this phase, the CLUE data channel setup takes place. If it completes successfully, the CPs are 
able to communicate and start the initiation phase. 


Negotiation of the CLUE protocol version and extensions (initiation phase): 
The CPs connected via the CLUE data channel agree on the protocol version and extensions to 
be used during the telepresence session. Special CLUE messages are used for such a task 
Coptions' and 'optionsResponse'). The negotiation of the version and extensions can be 
performed once during the CLUE session and only at this stage. At the end of that basic 
negotiation, each CP starts its activity as a CLUE MP and/or CLUE MC. 


Description and negotiation of CLUE telepresence capabilities: 
In this phase, the MP-MC dialogues take place on the data channel by means of the CLUE 
protocol messages. 


As soon as the channel is ready, the CPs must agree on the protocol version and extensions to be 
used within the telepresence session. CLUE protocol version numbers are characterized by a 
major version number and a minor version number, both unsigned integers, separated by a dot. 
While minor version numbers denote backward-compatible changes in the context of a given 
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major version, different major version numbers generally indicate a lack of interoperability 
between the protocol implementations. In order to correctly establish a CLUE dialogue, the 
involved CPs must have in common a major version number (see Section 7 for further details). 
The subset of the extensions that are allowed within the CLUE session is also determined in the 
initiation phase. It includes only the extensions that are supported by both parties. A mechanism 
for the negotiation of the CLUE protocol version and extensions is part of the initiation phase. 
According to such a solution, the CP that is the CLUE Channel Initiator (CI) issues a proper CLUE 
message (‘options’) to the CP that is the Channel Receiver (CR), specifying the supported version 
and extensions. The CR then answers by selecting the subset of the CI extensions that it is able to 
support and determines the protocol version to be used. 


After the negotiation phase is completed, CPs describe and agree on the media flows to be 
exchanged. In many cases, CPs will seek to both transmit and receive media. Hence, in a call 
between two CPs (e.g., CPs A and B), there would be two separate message exchange sequences, 
as follows: 


1. the one needed to describe and set up the media streams sent from A to B, i.e., the dialogue 
between A's MP side and B's MC side. 


2. the one needed to describe and set up the media streams sent from B to A, i.e., the dialogue 
between B's MP side and A's MC side. 


CLUE messages for the media session description and negotiation are designed by considering 
the MP side to be the server side of the protocol, since it produces and provides media streams, 
and the MC side as the client side of the protocol, since it requests and receives media streams. 
The messages that are exchanged to set up the telepresence media session are described by 
focusing on a single MP-MC dialogue. 


The MP first advertises its available media captures and encoding capabilities to the MC, as well 
as its simultaneity constraints, according to the information model defined in [RFC8845]. The 
CLUE message conveying the MP's multimedia offer is the 'advertisement' message. Such a 
message leverages the XML data model definitions provided in [RFC8846]. 


The MC selects the desired streams of the MP by using the 'configure' message, which makes 
reference to the information carried in the previously received ‘advertisement’. 


Besides ‘advertisement’ and 'configure', other messages have been conceived in order to provide 
all needed mechanisms and operations. Such messages are detailed in the following sections. 


5. Protocol Messages 


CLUE protocol messages are textual XML-based messages that enable the configuration of the 
telepresence session. The formal definition of such messages is provided in the XML schema in 
Section 9. This section includes non-normative excerpts of the schema to aid in describing it. 


The XML definitions of the CLUE information provided in [RFC8846] are included within some 
CLUE protocol messages (namely the 'advertisement' and 'configure' messages), in order to use 
the concepts defined in [RFC8845]. 
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The CLUE protocol messages are as follows: 


* options 

* optionsResponse 

* advertisement 

* ack 

* configure 

* configureResponse 


While the 'options' and 'optionsResponse' messages are exchanged in the initiation phase 
between the CPs, the other messages are involved in MP-MC dialogues. Please note that the word 
"dialogue" as used in this document is not related to SIP's usage of the same term. It refers to 
message exchange sequences between a CLUE MP and a Clue MC. 


Each CLUE message inherits a basic structure, as depicted in the following excerpt (Figure 1): 


«xs:complexType name-"clueMessageType" abstract="true"> 
«xs:sequence» 
<xs:element name="clueId" type="xs:string" minOccurs="0"/> 
<xs:element name="sequenceNr" type="xs:positiveInteger"/> 
</xs:sequence> 
<xs:attribute name="protocol" type="xs:string" fixed="CLUE" 
use="required"/> 
<xs:attribute name="v" type="versionType" use="required"/> 
</xs:complexType> 


<!== VERSION TYPE ==> 
<xs:simpleType name="versionType"> 
<xs:restriction base="xs:string"> 
«xs:pattern value="[1-9][0-9]*\.[0-9]+" /> 
</xs:restriction> 
</xs:simpleType> 


Figure 1: Structure of a CLUE Message 


The information contained in each CLUE message is as follows: 


clueld: An optional XML element containing the identifier (in the form of a generic string) of 
the CP within the telepresence system. 


sequenceNr: An XML element containing the local message sequence number. The sender MUST 
increment the sequence number by one for each new message sent, and the receiver MUST 
remember the most recent sequence number received and send back a 402 error if it receives 
a message with an unexpected sequence number (e.g., sequence number gap, repeated 
sequence number, sequence number too small). The initial sequence number can be chosen 
randomly by each party. 


protocol: A mandatory attribute set to "CLUE", identifying the protocol the messages refer to. 
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v: Amandatory attribute carrying the version of the protocol. The content of the "v" attribute is 
composed of the major version number followed by a dot and then by the minor version 
number of the CLUE protocol in use. The major number cannot be "0", and if it is more than 
one digit, it cannot start with a "0". Allowed values of this kind are "1.3", "2.0", "20.44", etc. This 
document describes version 1.0. 


Each CP is responsible for creating and updating up to three independent streams of sequence 
numbers in messages it sends: (i) one for the messages sent in the initiation phase, (ii) one for the 
messages sent as an MP (if it is acting as an MP), and (iii) one for the messages sent as an MC (if it 
is acting as an MC). 


In particular, CLUE response messages ('optionsResponse', ‘ack’, 'configureResponse') derive from 
a base type, inheriting from the clueMessageType, which is defined as follows (Figure 2): 


«xs:complexType name="clueResponseType"> 
«xs :complexContent> 
<xs:extension base="clueMessageType"> 
<xs:sequence> 
<xs:element name="responseCode" type="responseCodeType"/> 
<xs:element name="reasonString" type="xs:string" minOccurs="0"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 2: Structure of CLUE Response Messages 

The elements <responseCode> and <reasonString> are populated as detailed in Section 5.7. 
5.1. 'options' 

The 'options' message is sent by the CP that is the CI to the CP that is the CR as soon as the CLUE 


data channel is ready. Besides the information envisioned in the basic structure, it specifies: 


<mediaProvider>: A mandatory boolean field set to "true" if the CP is able to act as an MP. 
<mediaConsumer>: A mandatory boolean field set to "true" if the CP is able to act as an MC. 
<supportedVersions>: The list of supported versions. 


<supportedExtensions>: The list of supported extensions. 


The XML schema of such a message is shown below (Figure 3): 
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<!-- CLUE OPTIONS --> 
<xs:complexType name="optionsMessageType"> 
<xs:complexContent> 
<xs:extension base="clueMessageType"> 
<xs :sequence> 
<xs:element name="mediaProvider" type="xs:boolean" /> 
<xs:element name="mediaConsumer" type="xs:boolean" /> 
<xs:element name="supportedVersions" type="versionsListType" 
minOccurs="0"/> 
<xs:element name="supportedExtensions" 
type="extensionsListType" 
minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<!-- VERSIONS LIST TYPE --> 
<xs:complexType name="versionsListType"> 
<xs :sequence> 
<xs:element name="version" type="versionType" minOccurs="1" 
maxOccurs="unbounded" /> 
<xs:any namespace="##other" processContents="lax" minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:complexType> 


<!-- EXTENSIONS LIST TYPE --> 
<xs:complexType name="extensionsListType"> 
<xs :sequence> 
<xs:element name="extension" type="extensionType" minOccurs="1" 
maxOccurs="unbounded" /> 
<xs:any namespace="##other" processContents="lax" minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:complexType> 


<!-- EXTENSION TYPE --> 
<xs:complexType name="extensionType"> 
<xs :sequence> 
<xs:element name="name" type="xs:string" /> 
<xs:element name="schemaRef" type="xs:anyURI" /> 
<xs:element name="version" type="versionType" /> 
<xs:any namespace="##other" processContents="lax" minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:complexType> 


Figure 3: Structure of a CLUE 'options' Message 
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<supportedVersions> contains the list of versions that are supported by the CI, each one 
represented in a child <version> element. The content of each <version> element is a string made 
of the major version number followed by a dot and then by the minor version number (e.g., 1.3 
or 2.4). Exactly one <version> element MUST be provided for each major version supported, 
containing the maximum minor version number of such a version, since all minor versions are 
backward compatible. If no <supportedVersions> is carried within the 'options' message, the CI 
supports only the version declared in the "v" attribute and all the versions having the same 
major version number and lower minor version number. For example, if the "v" attribute has a 
value of "3.4" and there is no <supportedVersions> element in the 'options' message, it means the 
CI supports only major version 3 with all minor versions from 3.0 through 3.4. If 
<supportedVersions> is provided, at least one <version> element MUST be included. In this case, 
the "v" attribute SHOULD be set to the largest minor version of the smallest major version 
advertised in the <supportedVersions> list. Indeed, the intention behind the "v" attribute is that 
some implementation that receives a version number in the "v" field with a major number 
higher than it understands is supposed to close the connection, since it runs a risk of 
misinterpreting the contents of messages. The minor version is less useful in this context, since 
minor versions are defined to be both backward and forward compatible and the value can in 
any case be parsed out of the «version» list. It is more useful to know the highest minor version 
supported than some random minor version, as it indicates the full feature set that is supported. 


The <supportedExtensions> element specifies the list of extensions supported by the CI. If there is 
no <supportedExtensions> in the 'options' message, the CI does not support anything other than 
what is envisioned in the versions it supports. For each extension, an <extension> element is 
provided. An extension is characterized by a name, an XML schema of reference where the 
extension is defined, and the version of the protocol that the extension refers to. 


5.2. 'optionsResponse' 


The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply to the 'options' message. The 
'optionsResponse' contains a mandatory response code and a reason string indicating the 
processing result of the 'options' message. If the responseCode is between 200 and 299 inclusive, 
the response MUST also include <mediaProvider>, <mediaConsumer>, «version», and 
<commonExtensions> elements; it MAY include them for any other response code. 
<mediaProvider> and <mediaConsumer> elements (which are of a boolean nature) are 
associated with the supported roles (in terms of the MP and the MC, respectively), similarly to 
what the CI does in the 'options' message. The «version» element indicates the highest commonly 
supported version number. The content of the «version» element MUST be a string made of the 
major version number followed by a dot and then by the minor version number (e.g., 1.3 or 2.4). 
Finally, the commonly supported extensions are copied in the <commonExtensions> element. 
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<!-- CLUE 'optionsResponse' --> 
<xs:complexType name="optionsResponseMessageType"> 
<xs:complexContent> 
<xs:extension base="clueResponseType"> 
«xs:sequence» 
<xs:element name="mediaProvider" type="xs:boolean" 
minOccurs="0"/> 
<xs:element name="mediaConsumer" type="xs:boolean" 
minOccurs="0"/> 
<xs:element name="version" type="versionType" minOccurs="0"/> 
<xs:element name="commonExtensions" type="extensionsListType" 
minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 4: Structure of a CLUE 'optionsResponse' Message 


Upon reception of the 'optionsResponse', the version to be used is the one provided in the 
<version> element of the message. The subsequent CLUE messages MUST use such a version 
number in the "v" attribute. The allowed extensions in the CLUE dialogue are those indicated in 
the <commonExtensions> element of the 'optionsResponse' message. 


5.3. 'advertisement' 


The 'advertisement' message is used by each MP to advertise the available media captures and 
related information to the corresponding MC. The MP sends an 'advertisement' to the MC as soon 
as it is ready after the successful completion of the initiation phase, i.e., as soon as the CPs have 
agreed on the version and extensions of the CLUE protocol. During a single CLUE session, an MP 
may send new 'advertisement' messages to replace the previous advertisement if, for instance, its 
CLUE telepresence media capabilities change mid-call. A new 'advertisement' completely 
replaces the previous 'advertisement'. 


The 'advertisement' structure is defined in the schema excerpt below (Figure 5). The 
‘advertisement’ contains elements compliant with the CLUE data model that characterize the 
MP's telepresence offer. Namely, such elements are the list of 


* media captures (<mediaCaptures>), 

* encoding groups (<encodingGroups>), 

* capture scenes (<captureScenes>), 

* simultaneous sets (<simultaneousSets>), 
* global views (<globalViews>), and 

e represented participants («people»). 
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Each of them is fully described in the CLUE framework document [RFC8845] and formally 
defined in the CLUE data model document [RFC8846]. 


<!-- CLUE ADVERTISEMENT MESSAGE TYPE --> 
<xs:complexType name="advertisementMessagelype"> 
<xs:complexContent> 
<xs:extension base="clueMessageType"> 
<xs :sequence> 
<!-- mandatory --> 
<xs:element name="mediaCaptures" 
type="dm:mediaCapturesType" /> 
<xs:element name="encodingGroups" 
type="dm:encodingGroupsType"/> 
<xs:element name="captureScenes" 
type="dm:captureScenesType" /> 
<!-- optional --> 
<xs:element name="simultaneousSets" 
type="dm:simultaneousSetsType" minOccurs="0"/> 
<xs:element name="globalViews" type="dm:globalViewsType" 
minOccurs="0"/> 
<xs:element name="people" 
type="dm:peopleType" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 5: Structure of a CLUE 'advertisement' Message 


5.4. 'ack' 


The 'ack' message is sent by an MC to an MP to acknowledge an 'advertisement' message. As can 
be seen from the message schema provided in the following excerpt (Figure 6), the 'ack' contains 
a response code and may contain a reason string for describing the processing result of the 
‘advertisement’. The <advSequenceNr> element carries the sequence number of the 
'advertisement' message the 'ack' refers to. 
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<!-- 'ack' MESSAGE TYPE --> 
<xs:complexType name="advAcknowledgementMessageType"> 
<xs:complexContent> 
<xs:extension base="clueResponseType"> 
<xs:sequence> 
<xs:element name="advSequenceNr" type="xs:positiveInteger"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 6: Structure of a CLUE 'ack' Message 


5.5. 'configure' 


The 'configure' message is sent from an MC to an MP to list the advertised captures the MC wants 
to receive. The MC MUST send a 'configure' after the reception of an 'advertisement', as well as 
each time it wants to request other captures that have been previously advertised by the MP. The 
content of the 'configure' message is shown below (Figure 7). 


<!-- CLUE 'configure' MESSAGE TYPE --> 
<xs:complexType name="configureMessageType"> 
<xs:complexContent> 
<xs:extension base="clueMessageType"> 
<xs :sequence> 
<!-- mandatory fields --> 
<xs:element name="advSequenceNr" type="xs:positiveInteger"/> 
<xs:element name="ack" type="successResponseCodeType" 
minOccurs="0"/> 
<xs:element name="captureEncodings" 
type="dm:captureEncodingsType" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 7: Structure of a CLUE 'configure' Message 


The <advSequenceNr> element contains the sequence number of the 'advertisement' message the 
‘configure’ refers to. 
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The optional <ack> element, when present, contains a success response code, as defined in 
Section 5.7. It indicates that the 'configure' message also acknowledges with success the referred 
advertisement (‘configure+ack' message). The <ack> element MUST NOT be present if an 'ack' 
message (associated with the advertisement carrying that specific sequence number) has already 
been sent back to the MP. 


The most important content of the 'configure' message is the list of capture encodings provided in 
the <captureEncodings> element (see [RFC8846] for the definition of <captureEncodings>). Such 
an element contains a sequence of capture encodings, representing the streams to be 
instantiated. 


5.6. 'configureResponse' 


The 'configureResponse' message is sent from the MP to the MC to communicate the processing 
result of requests carried in the previously received 'configure' message. As shown in Figure 8, it 
contains a response code (and, optionally, a reason string) indicating either the success or failure 
(along with failure details) of the 'configure' request processing. The <confSequenceNr> element 
that follows contains the sequence number of the 'configure' message the response refers to. 
There is no partial execution of commands. As an example, if an MP is able to understand all the 
selected capture encodings except one, then the whole command fails and nothing is 
instantiated. 


<!-- 'configureResponse' MESSAGE TYPE --> 
<xs:complexType name="configureResponseMessageType"> 
<xs:complexContent> 
<xs:extension base="clueResponseType"> 
<xs :sequence> 
<xs:element name="confSequenceNr" 
type="xs:positiveInteger" /> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax" /> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 8: Structure of a CLUE 'configureResponse' Message 


5.7. Response Codes and Reason Strings 


Response codes are defined as a sequence of three digits. A well-defined meaning is associated 
with the first digit. Response codes beginning with "2" are associated with successful responses. 
Response codes that do not begin with either "2" or "1" indicate an error response, i.e., that an 
error occurred while processing a CLUE request. In particular, response codes beginning with "3" 
indicate problems with the XML content of the message ("Bad syntax", "Invalid value", etc.), 
while response codes beginning with "4" refer to problems related to CLUE protocol semantics 
("Invalid sequencing", "Version not supported", etc.). 200, 300, and 400 codes are the most generic 
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codes in their respective categories. Further response codes can be defined either in future 
versions of the protocol or by leveraging the extension mechanism. In both cases, the new 
response codes MUST be registered with IANA. Such new response codes MUST NOT override the 
codes defined in this document, and they MUST respect the semantics of the first code digit. 


This document does not define response codes starting with "1", and such response codes are not 
allowed to appear in major version 1 of the CLUE protocol. The range from 100 to 199 inclusive is 
reserved for future major versions of the protocol to define response codes for delayed or 
incomplete operations, if necessary. Response codes starting with "5" through "9" are reserved 
for future major versions of the protocol to define new classes of responses and are not allowed 
in major version 1 of the CLUE protocol. Response codes starting with "0" are not allowed. 


The response codes and reason strings defined for use with version 1 of the CLUE protocol are 
listed in Table 1. The "Description" text contained in the table can be sent in the <reasonString> 
element of a response message. Implementations can (and are encouraged to) include 
descriptions of the error condition that are more specific, if possible. 


Response Reason String Description 
Code 
200 Success The request has been successfully processed. 
300 Low-level request A generic low-level request error has occurred. 
error 
301 Bad syntax The XML syntax of the message is not correct. 
302 Invalid value The message contains an invalid parameter value. 
303 Conflicting values The message contains values that cannot be used 
together. 
400 Semantic errors The received CLUE protocol message contains semantic 
errors. 
401 Version not The protocol version used in the message is not 
supported supported. 
402 Invalid The received message contains an unexpected sequence 
sequencing number (e.g., sequence number gap, repeated sequence 


number, or sequence number outdated). 


403 Invalid identifier The clueld used in the message is invalid or unknown. 
404 Advertisement The sequence number of the advertisement the 
expired ‘configure’ message refers to is out of date. 
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Response Reason String Description 

Code 

405 Subset choice not The subset choice is not allowed for the specified 
allowed Multiple Content Capture. 


Table 1: CLUE Response Codes 


6. Protocol State Machines 


The CLUE protocol is an application protocol used between two CPs in order to properly 
configure a multimedia telepresence session. CLUE protocol messages flow over the CLUE data 
channel, an SCTP-over-DTLS channel established as depicted in [RFC8850]. We herein discuss the 
state machines associated with the CP (Figure 9), the MP role (Figure 10 in Section 6.1), and the 
MC role (Figure 11 in Section 6.2), respectively. Endpoints often wish to both send and receive 
media, i.e., act as both an MP and an MC. As such, there will often be two sets of messages 
flowing in opposite directions; the state machines of these two flows do not interact with each 
other. Only the CLUE application logic is considered. The interaction of CLUE protocol and SDP 
negotiations for the media streams exchanged is discussed in [RFC8848]. 
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Figure 9: CLUE Participant State Machine 
The main state machines focus on the behavior of the CP acting as a CLUE CI/CR. 


The initial state is the IDLE state. When in the IDLE state, the CLUE data channel is not 
established and no CLUE-controlled media are exchanged between the two CLUE-capable devices 
in question (if there is an ongoing exchange of media streams, such media streams are not 
currently CLUE controlled). 


When the CLUE data channel is set up ("start channel"), the CP moves from the IDLE state to the 
CHANNEL SETUP state. 


If the CLUE data channel is successfully set up ("channel established"), the CP moves from the 
CHANNEL SETUP state to the OPTIONS state. Otherwise, if a "channel error" occurs, it moves 
back to the IDLE state. The same transition happens if the CLUE-enabled telepresence session 
ends ("session ends"), i.e., when an SDP negotiation for removing the CLUE data channel is 
performed. 
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When in the OPTIONS state, the CP addresses the initiation phase where both parts agree on the 
version and extensions to be used in the subsequent CLUE message exchange phase. If the CP is 
the CI, it sends an 'options' message and waits for the 'optionsResponse' message. If the CP is the 
CR, it waits for the 'options' message and, as soon as it arrives, replies with the 'optionsResponse' 
message. If the negotiation is successfully completed ("OPTIONS phase success"), the CP moves 
from the OPTIONS state to the ACTIVE state. If the initiation phase fails ("OPTIONS phase 
failure"), the CP moves from the OPTIONS state to the IDLE state. The initiation phase might fail 
for one of the following reasons: 


1. The CI receives an 'optionsResponse' with an error response code. 
2. The CI does not receive any 'optionsResponse', and a timeout error is raised. 
3. The CR does not receive any ‘options’, and a timeout error is raised. 


When in the ACTIVE state, the CP starts the envisioned sub-state machines (i.e., the MP state 
machine and the MC state machine) according to the roles it plays in the telepresence sessions. 
Such roles have been previously declared in the 'options' and 'optionsResponse' messages 
involved in the initiation phase (see Sections 5.1 and 5.2 for details). When in the ACTIVE state, 
the CP delegates the sending and processing of the CLUE messages to the appropriate MP/MC sub- 
state machines. If the CP receives a further 'options'"optionsResponse' message, it MUST ignore 
the message and stay in the ACTIVE state. 


6.1. Media Provider's State Machine 


As soon as the sub-state machine of the MP (Figure 10) is activated, it is in the ADV state. In the 
ADV state, the MP prepares the 'advertisement' message reflecting its actual telepresence 
capabilities. 
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Figure 10: Media Provider's State Machine 


After the 'advertisement' has been sent ("advertisement sent"), the MP moves from the ADV state 
to the WAIT FOR ACK state. If an 'ack' message with a successful response code arrives ("ack 
received"), the MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an 'ack' message 
with an error response code), the MP moves back to the ADV state for preparation of a new 
‘advertisement’. When in the WAIT FOR ACK state, if a 'configure' message with the <ack> 
element set to "200" arrives ("configure*ack received"), the MP goes directly to the CONF 
RESPONSE state. 'configure*ack' messages referring to out-of-date (i.e., having a sequence 
number less than the highest generated so far) advertisements MUST be ignored, i.e., they do not 
trigger any state transition. If the telepresence settings of the MP change while in the WAIT FOR 
ACK state ("changed telepresence settings"), the MP switches from the WAIT FOR ACK state to the 
ADV state to create a new ‘advertisement’. 
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When in the WAIT FOR CONF state, the MP listens to the channel for a 'configure' request coming 
from the MC. When a 'configure' arrives ("configure received"), the MP switches to the CONF 
RESPONSE state. If the telepresence settings change in the meantime ("changed telepresence 
settings"), the MP moves from the WAIT FOR CONF state back to the ADV state to create the new 
‘advertisement' to be sent to the MC. 


The MP in the CONF RESPONSE state processes the received 'configure' in order to produce a 
'configureResponse' message. If the MP successfully processes the MC's configuration, then it 
sends a 200 'configureResponse' ("successful configureResponse sent") and moves to the 
ESTABLISHED state. If there are errors in the 'configure' processing, then the MP issues a 
'configureResponse' carrying an error response code and goes back to the WAIT FOR CONF state 
to wait for a new configuration request. Finally, if there are changes in the MP's telepresence 
settings ("changed telepresence settings"), the MP switches to the ADV state. 


The MP in the ESTABLISHED state has successfully negotiated the media streams with the MC by 
means of the CLUE messages. If there are changes in the MP's telepresence settings ("changed 
telepresence settings"), the MP moves back to the ADV state. In the ESTABLISHED state, the CLUE- 
controlled media streams of the session are those described in the last successfully processed 
'configure' message. 


Messages not shown for a state do not cause the state to change. 


6.2. Media Consumer's State Machine 


As soon as the sub-state machine of the MC (Figure 11) is activated, it is in the WAIT FOR ADV 
state. An MC in the WAIT FOR ADV state is waiting for an 'advertisement' coming from the MP. If 
the 'advertisement' arrives ("ADV received"), the MC moves to the ADV PROCESSING state. 
Otherwise, the MC stays in the WAIT FOR ADV state. 
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Figure 11: Media Consumer's State Machine 


In the ADV PROCESSING state, the 'advertisement' is parsed by the MC. If the 'advertisement' is 
successfully processed, two scenarios are possible. In the first case, the MC issues a successful 
'ack' message to the MP ("ack sent") and moves to the CONF state. This typically happens when 
the MC needs some more time to produce the 'configure' message associated with the received 
'advertisement'. In the latter case, the MC is able to immediately prepare and send back to the MP 
a 'configure' message. Such a message will have the <ack> element set to "200" ("configure+ack 
sent") and will allow the MC to move directly to the WAIT FOR CONF RESPONSE state. 


If the processing of the 'advertisement' is unsuccessful (bad syntax, missing XML elements, etc.), 
the MC sends a NACK message (i.e., an 'ack' with an error response code) to the MP and, 
optionally, further describes the problem via a proper reason phrase. In this scenario ("NACK 
sent"), the MC switches back to the WAIT FOR ADV state and waits for a new 'advertisement'. 
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When in the CONF state, the MC prepares the 'configure' request to be issued to the MP on the 
basis of the previously acked ‘advertisement’. When the 'configure' has been sent ("configure 
sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new ‘advertisement’ arrives in 
the meantime ("advertisement received"), the MC goes back to the ADV PROCESSING state. 


In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's response to the issued 
‘configure’ or 'configure+ack'. If a 200 'configureResponse' message is received ("successful 
configureResponse received"), it means that the MP and the MC have successfully agreed on the 
media streams to be shared. Then, the MC can move to the ESTABLISHED state. On the other 
hand, if an error response is received ("error configureResponse received"), the MC moves back 
to the CONF state to prepare a new 'configure' request. If a new ‘advertisement is received in the 
WAIT FOR CONF RESPONSE state, the MC switches to the ADV PROCESSING state. 


When the MC is in the ESTABLISHED state, the telepresence session configuration has been set up 
at the CLUE application level according to the MC's preferences. Both the MP and the MC have 
agreed on (and are aware of) the CLUE-controlled media streams to be exchanged within the call. 
While in the ESTABLISHED state, the MC might decide to change something in the call settings; in 
this case, the MC then issues a new 'configure' ("configure sent") and moves to the WAIT FOR 
CONF RESPONSE state to wait for the new 'configureResponse'. On the other hand, if the MC is in 
the ESTABLISHED state and a new 'advertisement' ("advertisement received") arrives from the 
MP, it means that something has changed on the MP's side; the MC then moves to the ADV 
PROCESSING state. 


Messages not shown for a state do not cause the state to change. 


7. Versioning 


CLUE protocol messages are XML messages compliant to the CLUE protocol XML schema 
[RFC8846]. The version of the protocol corresponds to the version of the schema. Both the client 
and the server have to test the compliance of the received messages with the XML schema of the 
CLUE protocol. If the compliance is not verified, the message cannot be processed further. 


The client and server cannot communicate if they do not share exactly the same XML schema. 
Such a schema is associated with the CLUE URN "urn:ietf:params:xml:ns:clue-protocol". If all 
CLUE-enabled devices use that schema, there will be no interoperability problems due to schema 
issues. 


This document defines version 1.0 of the CLUE protocol schema, using XML schema version 1.0 
[W3C.REC-xml-20081126]. The version usage is similar in philosophy to the Extensible Messaging 
and Presence Protocol (XMPP) [RFC6120]. A version number has major and minor components, 
each a non-negative integer. Changes to the major version denote non-interoperable changes. 
Changes to the minor version denote schema changes that are backward compatible by ignoring 
unknown XML elements or other backward-compatible changes. 


The minor versions of the XML schema MUST be backward compatible, not only in terms of the 
schema but semantically and procedurally as well. This means that they should define further 
features and functionality besides those defined in the previous versions, in an incremental way, 
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without impacting the basic rules defined in the previous version of the schema. In this way, if an 
MP is able to "speak", for example, version 1.5 of the protocol while the MC only understands 
version 1.4, the MP should have no problem in reverting the dialogue back to version 1.4 without 
exploiting 1.5 features and functionality. Version 1.4 is the one to be spoken and has to appear in 
the "v" attribute of the subsequent CLUE messages. In other words, in this example, the MP MUST 
use version 1.4. That said, and in keeping with the general IETF protocol "robustness principle" 
stating that an implementation must be conservative in its sending behavior and liberal in its 
receiving behavior [RFC1122], CPs MUST ignore unknown elements or attributes that are not 
envisioned in the negotiated protocol version and related extensions. 


8. Extensions 


Although the standard version of the CLUE protocol XML schema is designed to thoroughly cope 
with the requirements emerging from the application domain, new needs might arise, and new 
extensions can then be designed. Extensions specify information and behaviors that are not 
described in a certain version of the protocol and specified in the related RFC document. Such 
information and behaviors can be optionally used in a CLUE dialogue and MUST be negotiated in 
the CLUE initiation phase. They can relate to: 


1. new information, to be carried in the existing messages. For example, more fields may be 
added within an existing message. 


2. new messages. This is the case if there is no proper message for a certain task, so a brand 
new CLUE message needs to be defined. 


As to the first category of extensions, it is possible to distinguish between protocol-specific and 
data model information. Indeed, CLUE messages are envelopes carrying both of the following: 


1. XML elements defined within the CLUE protocol XML schema itself (protocol-specific 
information). 


2. other XML elements compliant to the CLUE data model schema (data model information). 


When new protocol-specific information is needed somewhere in the protocol messages, it can 
be added in place of the <any> elements and <anyAttribute> elements envisioned by the protocol 
schema. The policy currently defined in the protocol schema for handling <any> and 
<anyAttribute> elements is as follows: 


* elementFormDefault-"qualified" 
* attributeFormDefault-"unqualified" 


The new information must be qualified by namespaces other than "urn:ietf:params:xml:ns:clue- 
protocol" (the protocol URN) and "urn:ietf:params:xml:ns:clue-info" (the data model URN). 
Elements or attributes from unknown namespaces MUST be ignored. 


The other matter concerns data model information. Data model information is defined by the 
XML schema associated with the URN "urn:ietf:params:xml:ns:clue-info". Note that there are also 
extensibility issues for the XML elements defined in such a schema. Those issues are overcome 
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by using <any> and <anyAttribute> placeholders. New information within data model elements 
can be added in place of <any> and <anyAttribute> schema elements, as long as they are properly 
namespace qualified. 


On the other hand (the second category of extensions), "extra" CLUE protocol messages, i.e., 
messages not envisioned in the latest standard version of the schema, might be needed. In that 
case, the messages and the associated behavior should be defined in external documents that 
both communication parties must be aware of. 


As shown in Figure 12, the fields of the <extension> element (either new information or new 
messages) take the following values: 


*a name. 


* an external XML schema defining the XML information and/or the XML messages 
representing the extension. 


e the major standard version of the protocol that the extension refers to. 


«xs:complexType name="extensionType"> 
«xs:sequence» 
<xs:element name="name" type="xs:string" /» 
<xs:element name="schemaRef" type="xs:anyURI" /> 
<xs:element name="version" type="versionType"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:complexType> 


Figure 12: The <extension> Element 


The above-described <extension> element is carried within the 'options' and 'optionsResponse' 
messages to represent the extensions supported by both the CI and the CR. 


Extensions MUST be defined in a separate XML schema file and MUST be provided with a 
companion document describing their semantics and use. 


8.1. Extension Example 


An example of an extension might be a "new" capture attribute (i.e., a capture attribute that is 
not envisioned in the current standard defining the CLUE data model in [RFC8846]) needed to 
further describe a video capture. 


The CLUE data model document [RFC8846] envisions the possibility of adding this kind of "extra" 
information in the description of a video capture. For convenience, the XML definition of a video 
capture taken from [RFC8846] is shown in Figure 13 below. 
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<!-- VIDEO CAPTURE TYPE --> 
<xs:complexType name="videoCaptureType"> 
<xs :complexContent> 
<xs:extension base="tns:mediaCaptureType"> 
<xs :sequence> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" 
maxOccurs="unbounded" /> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


Figure 13: XML Definition of a CLUE Video Capture 


According to such a definition, a video capture might have, after the set of generic media capture 
attributes, a set of new attributes defined elsewhere, i.e., in an XML schema defining an 
extension. The XML schema defining the extension might look like the following (Figure 14): 


<?xml version="1.0" encoding="UTF-8" ?> 

<xs:schema version="1.0" 
targetNamespace="https://example.extensions.com/myVideoExtensions" 
xmlns:xs="https://www.w3.org/2001/XMLSchema" 
xmlns="https://example.extensions.com/myVideoExtensions" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<!-- 
This is the new element to be put in place of the <any> 
element in the video capture definition 
of the CLUE data model schema 


--» 


<xs:element name="myVideoExtension"> 
«xs :complexType> 
«xs:sequence» 
<xs:element ref="newVideoAttributel"/> 
<xs:element ref="newVideoAttribute2"/> 
«/xs:sequence» 
</xs:complexType> 
</xs:element> 


<xs:element name="newVideoAttribute1" type="xs:string"/> 


<xs:element name = "newVideoAttribute2" type = "xs:boolean"/> 
</xs:schema> 


Figure 14: XML Schema Defining an Extension 
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By using the extension above, a video capture can be further described in the advertisement 
using the <myVideoExtension> element containing two extra pieces of information 
(<newVideoAttribute1> and <newVideoAttribute2>), besides using the attributes envisioned for a 
generic media capture. As stated in this document, both participants must be aware of the 
extension schema and related semantics to use such an extension and must negotiate it via the 
‘options’ and 'optionsResponse' messages. 


9. XML Schema 


The XML schema defining the CLUE messages is provided below (Figure 15). 
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<?xml version="1.0" encoding="UTF-8" ?> 
«xs:schema xmlns:xs="https://www.w3.0rg/2001/XMLSchema" 


xmlns="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:dm="urn:ietf:params:xml:ns:clue-info" 
version="1.0" 
targetNamespace="urn:ietf:params:xml:ns:clue-protocol" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<!-- Import data model schema --> 


<XS 


‘import namespace="urn:ietf:params:xml:ns:clue-info"/> 


<!-- ELEMENT DEFINITIONS --> 


<XS 
<XS 


<XS 
<XS 
<XS 
<XS 


‘element name="options" type="optionsMessageType" /> 

‘element name="optionsResponse" 
type="optionsResponseMessageType" /> 

:element name="advertisement" type="advertisementMessageType"/> 

"element name="ack" type="advAcknowledgementMessageType" /> 

element name="configure" type="configureMessageType"/> 

‘element name="configureResponse" 
type="configureResponseMessageType" /> 


<!-- CLUE MESSAGE TYPE --> 


<XS 


:complexType name="clueMessageType" abstract="true"> 


<xs:sequence> 


<xs:element name="clueId" type="xs:string" minOccurs="0" /» 
<xs:element name="sequenceNr" type="xs:positiveInteger" /> 


«/xs:sequence» 
«xs:attribute name="protocol" type="xs:string" fixed="CLUE" 


use-"required" /» 


«xs:attribute name="v" type="versionType" use-"required" /> 
</xs:complexType> 
<!-- CLUE RESPONSE TYPE --> 


<XS 


:complexType name="clueResponseType"> 


«xs :complexContent> 


<xs:extension base="clueMessageType"> 
«xs:sequence» 
<xs:element name="responseCode" type="responseCodeType" /» 
<xs:element name="reasonString" type="xs:string" 
minOccurs="0"/> 
«/xs:sequence» 
«/xs:extension» 


</xs:complexContent> 
</xs:complexType> 
<!-- VERSION TYPE --> 


<XS 


:simpleType name="versionType"> 


<xs:restriction base="xs:string"> 


«xs:pattern value="[1-9][0-9]*\.[0-9]+" /> 


</xs:restriction> 
</xs:simpleType> 
<!-- RESPONSE CODE TYPE --> 


<XS 


:simpleType name="responseCodeType"> 


<xs:restriction base="xs:integer"> 


<xs:pattern value-"[1-9][0-9][0-9]" /> 


</xs:restriction> 
</xs:simpleType> 
<!-- SUCCESS RESPONSE CODE TYPE --> 


<XS 


:simpleType name="successResponseCodeType"> 


<xs:restriction base="xs:integer"> 


<xs:pattern value="2[0-9][0-9]" /> 
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</xs:restriction> 
</xs:simpleType> 
<!-- CLUE OPTIONS --> 
<xs:complexType name="optionsMessageType"> 
<xs:complexContent> 
<xs:extension base="clueMessageType"> 
«xs:sequence» 
<xs:element name="mediaProvider" type="xs:boolean"/> 
<xs:element name="mediaConsumer" type="xs:boolean" /> 
<xs:element name="supportedVersions" 
type="versionsListType" 
minOccurs="0" /> 
<xs:element name="supportedExtensions" 
type="extensionsListType" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<!-- VERSIONS LIST TYPE --> 
<xs:complexType name="versionsListType"> 
«xs:sequence» 
<xs:element name="version" type="versionType" minOccurs="1" 
maxOccurs="unbounded" /> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax" /» 
</xs:complexType> 
<!-- EXTENSIONS LIST TYPE --> 
<xs:complexType name="extensionsListType"> 
<xs:sequence> 
<xs:element name="extension" type="extensionType" 
minOccurs="1" 
maxOccurs="unbounded" /> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax" /» 
</xs:complexType> 
<!-- EXTENSION TYPE --> 
<xs:complexType name="extensionType"> 
«xs:sequence» 
<xs:element name="name" type="xs:string" /» 
<xs:element name="schemaRef" type="xs:anyURI" /> 
<xs:element name="version" type="versionType" /> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:complexType> 
<!-- CLUE 'optionsResponse' --> 
<xs:complexType name="optionsResponseMessageType' > 
<xs :complexContent> 
<xs:extension base="clueResponseType"> 
«xs:sequence» 
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<xs:element name="mediaProvider" type="xs:boolean" 
minOccurs="0"/> 
<xs:element name="mediaConsumer" type="xs:boolean" 
minOccurs="0"/> 
<xs:element name="version" type="versionType" 
minOccurs="0"/> 
<xs:element name="commonExtensions" 
type="extensionsListType" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<!-- CLUE ADVERTISEMENT MESSAGE TYPE --> 
<xs:complexType name="advertisementMessageType "> 
<xs:complexContent> 
<xs:extension base="clueMessageType"> 
«xs:sequence» 
<!-- mandatory --» 
<xs:element name="mediaCaptures" 
type="dm:mediaCapturesType"/> 
<xs:element name="encodingGroups" 
type="dm:encodingGroupsType" /> 
<xs:element name="captureScenes" 
type="dm:captureScenesType"/> 
<!-- optional --> 
<xs:element name="simultaneousSets" 
type="dm:simultaneousSetsType" minOccurs="0"/> 
<xs:element name="globalViews" type="dm:globalViewsType" 
minOccurs="0"/> 
<xs:element name="people" 
type="dm:peopleType" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<!-- 'ack' MESSAGE TYPE --> 
<xs:complexType name="advAcknowledgementMessageType"> 
<xs :complexContent> 
<xs:extension base="clueResponseType"> 
«xs:sequence» 
<xs:element name="advSequenceNr" 
type="xs:positiveInteger"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<!-- CLUE 'configure' MESSAGE TYPE --> 
<xs:complexType name="configureMessageType"> 
<xs:complexContent> 
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<xs:extension base="clueMessageType"> 
«xs:sequence» 
«!-- mandatory fields --> 
<xs:element name="advSequenceNr" 
type="xs:positiveInteger"/> 
<xs:element name="ack" type="successResponseCodeType" 
minOccurs="0"/> 
<xs:element name="captureEncodings" 
type="dm:captureEncodingsType" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<!-- 'configureResponse' MESSAGE TYPE --> 
«xs:complexType name="configureResponseMessageType "> 
<xs:complexContent> 
<xs:extension base="clueResponseType"> 
«xs:sequence» 
<xs:element name="confSequenceNr" 
type="xs:positiveInteger"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0"/> 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
</xs:schema> 


Figure 15: Schema Defining CLUE Messages 
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10. Call Flow Example 


This section describes the CLUE protocol messages exchanged in the following call flow. For 
simplicity, only one direction of media is shown, as the other direction is precisely symmetric. 


| 

| 

| 

| 

| 

| 

T 

| 

| | 

3. advertisement | 
+-------------------- >| 
| | 
| | 
|4. configure+ack | 
(SS a + 
| | 
| | 
|5. configureResponse | 
+-------------------- >| 
| | 
| | 
|6. advertisement | 
+-------------------- >| 
| | 
| | 
| 7. ack | 
[Re RRR SSS SSS EE + 
| | 
| | 
|8. configure | 
[SS SS SS SS cus ite de + 
| | 
| | 
| | 
| 

| 
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Two CPs, CP1 and CP2, have successfully set up the CLUE channel according to [RFC8850]. CP1 is 
the CI, and CP2 is the CR. 


e The initiation phase starts (negotiation of the CLUE protocol version and extensions). CP1, as 
the CI, sends to CP2 an 'options' message specifying the supported versions and extensions 
(Section 10.1). CP1 supports (i) version 1.4 with extensions E1, E2, and E3 and (ii) version 2.7 
with extensions E4 and E5. Because of such capabilities, CP1 sends an 'options' message with 
the "v" attribute set to "1.4" and explicitly specifies all the supported versions and extensions 
in the corresponding fields of the 'options' message. In the 'options' message, CP1 also 
specifies that it intends to act as both an MP and an MC. 


* CP2 supports versions 3.0, 2.9, and 1.9 of the CLUE protocol, each version without any 
extensions. Version 2.7 is the best common choice. Given the received 'options' message, CP2 
answers with an 'optionsResponse' message in which it specifies only version 2.7 as the 
agreed-upon version of the CLUE protocol to be used, leaving blank the extensions part of 
the message to say that no extensions will be used in the CLUE session (Section 10.2). In the 
'optionsResponse' message, CP2 also specifies that it intends to act as both an MP and an MC. 


After the initiation phase is completed, CP1 and CP2 start their activity as the MP and the MC, 
respectively. For the sake of simplicity, the rest of the call flow focuses only on the dialogue 
between MP CP1 and MC CP2. 


* CP1 advertises a telepresence configuration like the one described in [RFC8846], Section 27, 
where there are (i) three main video streams captured by three cameras, with the central 
camera capable of capturing a zoomed-out view of the overall telepresence room, (ii) a 
multicontent capture of the loudest segment of the room, and (iii) one audio capture for the 
audio of the whole room (Section 10.3). 


* CP2 receives CP1's 'advertisement' message and, after processing it, sends back to CP1 a 
'configure+ack' message in which it declares its interest in the multicontent capture and the 
audio capture only (Section 10.4). 

e CP1 answers CP2's 'configure+ack' message with a 'configureResponse' message that includes 
a 200 (Success) response code to accept all of CP2's requests (Section 10.5). 

* To reflect the changes in its telepresence offer, CP1 issues a new ‘advertisement’ message to 
CP2 (Section 10.6), this time also adding a composed capture made of a big picture 
representing the current speaker and two picture-in-picture boxes representing the previous 
speakers (see [RFC8846], Section 28 for more details regarding the telepresence description). 

e CP2 acknowledges the second ‘advertisement’ message with an 'ack' message (Section 10.7). 

* Later in the session, CP2 changes the requested media streams from CP1 by sending to CP1 a 
‘configure’ message replacing the previously selected video streams with the new composed 
media streams advertised by CP1 (Section 10.8). Media streams from the previous 
configuration continue to flow during the reconfiguration process. 


* Finally, CP1 accepts CP2's latest request with a 'configureResponse' message (Section 10.9). 
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We would also like to point out that in the depicted flow three distinct sequence number spaces 
per sender are involved (two of which appear in the snippets, since we only show one direction 
of media). The discontinuity between the sequence number values in Sections 10.2 and 10.3 is 
hence correct. 


10.1. CLUE Message No. 1: 'options' 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
«options xmlns-"urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol-"CLUE" v="1.4"> 
<clueId>CP1</clueId> 
<sequenceNr>51</sequenceNr> 
<mediaProvider>true</mediaProvider> 
<mediaConsumer>true</mediaConsumer> 
<supportedVersions> 
<version>1.4</version> 
<version>2.7</version> 
</supportedVersions> 
<supportedExtensions> 
<extension> 
<name>E1</name> 
<schemaRef>URL_E1</schemaRef> 
<version>1.4</version> 
</extension> 
<extension> 
<name>E2</name> 
<schemaRef>URL_E2</schemaRef> 
<version>1.4</version> 
</extension> 
<extension> 
<name>E3</name> 
<schemaRef>URL_E3</schemaRef> 
<version>1.4</version> 
</extension> 
<extension> 
<name>E4</name> 
<schemaRef>URL_E4</schemaRef> 
<version>2.7</version> 
</extension> 
<extension> 
<name>E5</name> 
<schemaRef>URL_E5</schemaRef> 
<version>2.7</version> 
</extension> 
</supportedExtensions> 
</options> 
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10.2. CLUE Message No. 2: 'optionsResponse' 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
«optionsResponse xmlns="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE” v="1.4"> 
<clueId>CP2</clueId> 
<sequenceNr>62</sequenceNr> 
<responseCode>200</responseCode> 
<reasonString>Success</reasonString> 
<mediaProvider>true</mediaProvider> 
<mediaConsumer>true</mediaConsumer> 
<version>2.7</version> 
</optionsResponse> 
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10.3. CLUE Message No. 3: 'advertisement' 
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<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns2:advertisement xmlns="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE" v="2.7"> 
<ns2:clueId>CP1</ns2:clueId> 
<ns2:sequenceNr>11</ns2:sequenceNr> 
<ns2 :mediaCaptures> 
<mediaCapture 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
xsi:type="audioCaptureType" captureID="AC0" 
mediaType="audio"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<capture0rigin> 
<capturePoint> 
<x>0.0</x> 
<y>0.0</y> 
«z»10.0«/z» 
</capturePoint> 
<lineOfCapturePoint> 
<x>0.0</x> 
<y>1.0</y> 
«z»10.0«/z» 
«/lineOfCapturePoint» 
</capture0rigin> 
</spatialInformation> 
<individual>true</individual> 
<encGroupIDREF>EG1</encGroupIDREF> 
<description lang="en">main audio from the room 
</description> 
<priority>1</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>room</view> 
<capturedPeople> 
<personIDREF>alice</personIDREF> 
<personIDREF>bob</personIDREF> 
<personIDREF>ciccio</personIDREF> 
</capturedPeople> 
</mediaCapture> 
<mediaCapture 
xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID="VC0" 
mediaType="video"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<capture0rigin> 
<capturePoint> 
<x>-2.0</x> 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
</capture0rigin> 
<captureArea> 
<bottomLeft> 
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<x>-3.0</x> 
<y>20.0</y> 
<z>9.0</z> 
</bottomLeft> 
<bottomRight> 
<x>-1.0</x> 
<y>20.0</y> 
<z>9.0</z> 
</bottomRight> 
<topLeft> 
<x>-3.0</x> 
<y>20.0</y> 
<Z>11.0</z> 
</topLeft> 
<topRight> 
<x>-1.0</x> 
<y>20.0</y> 
<Z>11.0</z> 
</topRight> 


</captureArea> 
</spatialInformation> 
<individual>true</individual> 


<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">left camera video capture 


</description> 
<priority>1</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 


<capturedPeople> 


<personIDREF>ciccio</personIDREF> 


</capturedPeople> 


</mediaCapture> 
<mediaCapture 
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xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID="VC1" 


mediaType="video"> 


<captureSceneIDREF>CS1</captureSceneIDREF> 


<spatialInformation> 
<capture0rigin> 


<capturePoint> 
<x>0 .0</x> 
<y>0.B</y> 
<z>10.0</z> 


</capturePoint> 
</captureOrigin> 
<captureArea> 


<bottomLeft> 
<x>-1.0</x> 
<y>20.0</y> 
<z>9.0</z> 
</bottomLeft> 
<bottomRight> 
<x>1.0</x> 
<y>20.0</y> 
<z>9.0</z> 
</bottomRight> 
<topLeft> 
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<x>-1.0</x> 
<y>20.0</y> 
«z»11.0«/z» 
«/topLeft» 
«topRight» 
«x»1.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
</topRight> 
</captureArea> 


</spatialInformation> 


CLUE 


<individual>true</individual> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">central camera video 


</description> 


<priority>1</priority> 


<lang>it</lang> 


<mobility>static</mobility> 


<view>individual</view> 
<capturedPeople> 


<personIDREF>alice</personIDREF> 


</capturedPeople> 


</mediaCapture> 
<mediaCapture 


capture 


xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID-"VC2" 


mediaType="video"> 


<captureSceneIDREF>CS1</captureSceneIDREF> 


<spatialInformation> 


<capture0rigin> 


<capturePoint> 


«x22.0«/x» 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
</capture0rigin> 
<captureArea> 


<bottomLeft> 


<x>1.0</x> 
<y>20.0</y> 
<z>9.0</z> 


</bottomLeft> 
<bottomRight> 


<x>3.0</x> 
<y>20.0</y> 
<z>9.0</z> 


</bottomRight> 


<topLeft> 
<x>1.0</x> 
<y>20.0</y> 
«z»11.0«/z» 
«/topLeft» 
«topRight» 
«x23.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
«/topRight» 
</captureArea> 
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</spatialInformation> 
<individual>true</individual> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">right camera video capture 
</description> 
<priority>1</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 
<capturedPeople> 
<personIDREF>bob</personIDREF> 
</capturedPeople> 


</mediaCapture> 

<mediaCapture 
xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID="VC3" 
mediaType="video"> 


<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<captureArea> 
<bottomLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
<z>9.0</Z> 
</bottomLeft> 
<bottomRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>9.0</z> 
</bottomRight> 
<topLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
«/topLeft» 
«topRight» 
«x23.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
«/topRight» 
</captureArea> 
</spatialInformation> 
<content> 
<sceneViewIDREF>SE1</sceneViewIDREF> 
</content> 
<policy>SoundLevel:0</policy> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">loudest room segment 
</description> 
<priority>2</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 
</mediaCapture> 


<mediaCapture 
xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID="VC4" 
mediaType="video"> 
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<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<capture0rigin> 
<capturePoint> 
«x20.0«/x» 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
</captureOrigin> 
<captureArea> 
<bottomLeft> 
<x>-3.0</x> 
<y>20.0</y> 
<z>7.0</Z> 
</bottomLeft> 
<bottomRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>7.0</Z> 
</bottomRight> 
<topLeft> 
<x>-3.0</x> 
<y>20.0</y> 
<z>13.0</Z> 
</topLeft> 
<topRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>13.0</Z> 
</topRight> 
</captureArea> 
</spatialInformation> 
<individual>true</individual> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">zoomed-out view of all 
the room</description> 
<priority>2</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>room</view> 
<capturedPeople> 
<personIDREF>alice</personIDREF> 
<personIDREF>bob</personIDREF> 
<personIDREF>ciccio</personIDREF> 
</capturedPeople> 
</mediaCapture> 
</ns2:mediaCaptures> 
<ns2:encodingGroups> 
«encodingGroup encodingGroupID="EG@"> 
<maxGroupBandwidth>600000</maxGroupBandwidth> 
<encodingIDList> 
<encodingID>ENC1</encodingID> 
<encodingID>ENC2</encodingID> 
<encodingID>ENC3</encodingID> 
</encodingIDList> 
</encodingGroup> 
«encodingGroup encodingGroupID-"EG1"» 
<maxGroupBandwidth>300000</maxGroupBandwidth> 
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<encodingIDList> 
<encodingID>ENC4</encodingID> 
<encodingID>ENC5</encodingID> 

</encodingIDList> 


</encodingGroup> 
</ns2:encodingGroups> 
<ns2 :captureScenes> 
<captureScene scale="unknown" sceneID="CS1"> 


<sceneViews> 
<sceneView sceneViewID="SE1"> 
<mediaCaptureIDs> 
<mediaCaptureIDREF>VC0</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC1</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC2</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE2"> 
«mediaCaptureIDs» 
<mediaCaptureIDREF>VC3</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE3"> 
«mediaCaptureIDs» 
<mediaCaptureIDREF>VC4</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE4"> 
<mediaCaptureIDs> 
<mediaCaptureIDREF>AC0</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
</sceneViews> 


</captureScene> 
</ns2:captureScenes> 
«ns2:simultaneousSets» 

«simultaneousSet setID="SS1"> 


<mediaCaptureIDREF>VC3</mediaCaptureIDREF> 
<sceneViewIDREF>SE1</sceneViewIDREF> 


</simultaneousSet> 
<simultaneousSet setID="SS2"> 


<mediaCaptureIDREF>VC0</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC2</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC4</mediaCaptureIDREF> 


</simultaneousSet> 
</ns2:simultaneousSets> 
«ns2 :people> 

<person personID="bob"> 


<personInfo> 
<ns3 :fn> 
<ns3 : text>Bob</ns3 : text> 
</ns3:fn> 
</personInfo> 
<personType>minute taker</personType> 


</person> 
«person personID="alice"> 


<personInfo> 
<ns3 :fn> 
<ns3:text>Alice</ns3:text> 
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</ns3:fn> 
</personInfo> 
<personType>presenter</personType> 
</person> 
<person personID="ciccio"> 
<personInfo> 
«ns3:fn» 
<ns3:text>Ciccio</ns3:text> 
</ns3:fn> 
</personInfo> 
<personType>chairman</personType> 
<personType>timekeeper</personType> 
</person> 
</ns2:people> 
</ns2:advertisement> 


10.4. CLUE Message No. 4: 'configure+ack' 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns2:configure xmlns="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE" v="2.7"> 

<ns2:clueId>CP2</ns2:clueId> 

<ns2 :sequenceNr>22</ns2 :sequenceNr> 

<ns2 :advSequenceNr>11</ns2:advSequenceNr> 

<ns2 :ack>200</ns2 :ack> 

«ns2:captureEncodings» 

«captureEncoding ID="ce123"> 
<captureID>AC0</captureID> 
<encodingID>ENC4</encodingID> 

</captureEncoding> 

<captureEncoding ID="ce223"> 
<captureID>VC3</captureID> 
<encodingID>ENC1</encodingID> 
<configuredContent> 

<sceneViewIDREF>SE1</sceneViewIDREF> 
</configuredContent> 
</captureEncoding> 
</ns2:captureEncodings> 
</ns2:configure> 
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10.5. CLUE Message No. 5: 'configureResponse' 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns2:configureResponse xmlns="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE” v="2.7"> 
<ns2:clueId>CP1</ns2:clueId> 
<ns2:sequenceNr>12</ns2:sequenceNr> 
<ns2:responseCode>200</ns2:responseCode> 
<ns2:reasonString>Success</ns2:reasonString> 
<ns2 :confSequenceNr>22</ns2 :confSequenceNr> 
</ns2:configureResponse> 
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10.6. CLUE Message No. 6: 'advertisement' 
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<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns2:advertisement xmlns="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE" v="2.7"> 
<ns2:clueId>CP1</ns2:clueId> 
<ns2 :sequenceNr>13</ns2 :sequenceNr> 
<ns2 :mediaCaptures> 
<mediaCapture 
xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema-instance" 
xsi:type="audioCaptureType" captureID-"ACO" 
mediaType="audio"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<capture0rigin> 
<capturePoint> 
«x20.0«/x» 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
<lineOfCapturePoint> 
«x20.0«/x» 
<y>1.B</y> 
<Z>10.0</z> 
</lineOfCapturePoint> 
</capture0rigin> 
</spatialInformation> 
<individual>true</individual> 
<encGroupIDREF>EG1</encGroupIDREF> 
<description lang="en">main audio from the room 
</description> 
<priority>1</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>room</view> 
<capturedPeople> 
<personIDREF>alice</personIDREF> 
<personIDREF>bob</personIDREF> 
<personIDREF>ciccio</personIDREF> 
</capturedPeople> 
</mediaCapture> 
<mediaCapture 
xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID="VC0" 
mediaType="video"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<capture0rigin> 
<capturePoint> 
<x>0.5</x> 
<y>1.B</y> 
<z>0.5</Z> 
</capturePoint> 
<lineOfCapturePoint> 
«x20.5«/x» 
<y>0.B</y> 
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<z>0.5</Z> 
</lineOfCapturePoint> 
</captureOrigin> 
</spatialInformation> 
<individual>true</individual> 


<encGroupIDREF>EG@</encGroupIDREF> 


<description lang="en">left camera video capture 


</description> 
<priority>1</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 
<capturedPeople> 


<personIDREF>ciccio</personIDREF> 
</capturedPeople> 


</mediaCapture> 
<mediaCapture 


xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 

xsi:type="videoCaptureType" captureID="VC1" 

mediaType="video"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 
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<spatialInformation> 
<capture0rigin> 
<capturePoint> 
«x20.0«/x» 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
</captureOrigin> 
<captureArea> 
<bottomLeft> 
«x»-1.0«/x» 
<y>20.0</y> 
<z>9.0</Z> 
</bottomLeft> 
<bottomRight> 
<x>1.0</x> 
<y>20.0</y> 
<z>9.0</Z> 
</bottomRight> 
<topLeft> 
<x>-1.0</x> 
<y>20.0</y> 
«z»11.0«/z» 
«/topLeft» 
«topRight» 
<x>1.0</x> 
<y>20.0</y> 
«z»11.0«/z» 
«/topRight» 
</captureArea> 
</spatialInformation> 
<individual>true</individual> 


<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">central camera video 


</description> 
<priority>1</priority> 
<lang>it</lang> 
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<mobility>static</mobility> 
<view>individual</view> 
<capturedPeople> 
<personIDREF>alice</personIDREF> 
</capturedPeople> 
</mediaCapture> 
<mediaCapture 
xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema- instance" 
xsi:type="videoCaptureType" captureID-"VC2" 
mediaType="video"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<capture0rigin> 
<capturePoint> 
«x22.0«/x» 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
</capture0rigin> 
<captureArea> 
<bottomLeft> 
<x>1.0</x> 
<y>20.0</y> 
<z>9.0</Z> 
</bottomLeft> 
<bottomRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>9.0</z> 
</bottomRight> 
<topLeft> 
<x>1.0</x> 
<y>20.0</y> 
<Z>11.0</z> 
</topLeft> 
<topRight> 
<x>3.0</x> 
<y>20.0</y> 
<z>11.0</Z> 
</topRight> 
</captureArea> 
</spatialInformation> 
<individual>true</individual> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">right camera video capture 
</description> 
<priority>1</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 
<capturedPeople> 
<personIDREF>bob</personIDREF> 
</capturedPeople> 
</mediaCapture> 
<mediaCapture 
xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID-"VC3" 
mediaType="video"> 
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<captureSceneIDREF>CS1</captureSceneIDREF> 


<spatialInformation> 
<captureArea> 
<bottomLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
«z»9.0«/z» 
«/bottomLeft» 
«bottomRight» 
<x>3.B</x> 
<y>20.0</y> 
<z>9.B</Z> 
</bottomRight> 
<topLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
<z>11.0</Z> 
</topLeft> 
<topRight> 
<x>3.0</x> 
<y>20.0</y> 
«z»11.0«/z» 
</topRight> 
</captureArea> 
</spatialInformation> 
<content> 


<sceneViewIDREF>SE1</sceneViewIDREF> 


</content> 
<policy>SoundLevel:0</policy> 


<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">loudest room segment 


</description> 
<priority>2</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 


</mediaCapture> 
<mediaCapture 
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xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID="VC4" 

mediaType="video"> 
<captureSceneIDREF>CS1</captureSceneIDREF> 


<spatialInformation> 
<capture0rigin> 
<capturePoint> 
«x20.0«/x» 
<y>0.B</y> 
<Z>10.0</z> 
</capturePoint> 
</captureOrigin> 
<captureArea> 
<bottomLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
<z>7.0</Z> 
</bottomLeft> 
<bottomRight> 
«x23.0«/x» 
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<y>20.0</y> 
<z>7.0</Z> 
</bottomRight> 
<topLeft> 
<x>-3.0</x> 
<y>20.0</y> 
<z>13.0</Z> 
</topLeft> 
<topRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>13.0</Z> 
</topRight> 
</captureArea> 
</spatialInformation> 
<individual>true</individual> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en"> 
zoomed-out view of all people in the 
</description> 
<priority>2</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>room</view> 
<capturedPeople> 
<personIDREF>alice</personIDREF> 
<personIDREF>bob</personIDREF> 
<personIDREF>ciccio</personIDREF> 
</capturedPeople> 


</mediaCapture> 
<mediaCapture 

xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID-"VC5" 
mediaType="video"> 


room 


<captureSceneIDREF>CS1</captureSceneIDREF> 


<spatialInformation> 

<captureArea> 
<bottomLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
<z>9.0</z> 
</bottomLeft> 
<bottomRight> 
<x>3.0</x> 
<y>20.0</y> 
<z>9.B</Z> 
</bottomRight> 
<topLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
«/topLeft» 
«topRight» 
«x»3.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
«/topRight» 

</captureArea> 
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</spatialInformation> 
<content> 
<sceneViewIDREF>SE1</sceneViewIDREF> 
</content> 


<policy>SoundLevel:1</policy> 

<description lang="en">penultimate loudest room segment 
</description> 

<lang>it</lang> 

<mobility>static</mobility> 

<view>individual</view> 


</mediaCapture> 

<mediaCapture 
xmlns:xsi="https://ww.w3.0rg/2001/XMLSchema-instance" 
xsi:type="videoCaptureType" captureID-"VC6" 
mediaType="video"> 


<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<captureArea> 
<bottomLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
<z>9.0</z> 
</bottomLeft> 
<bottomRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>9.0</Z> 
</bottomRight> 
<topLeft> 
«x»-3.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
«/topLeft» 
«topRight» 
«x23.0«/x» 
<y>20.0</y> 
«z»11.0«/z» 
</topRight> 
</captureArea> 
</spatialInformation> 
<content> 
<sceneViewIDREF>SE1</sceneViewIDREF> 
</content> 
<policy>SoundLevel:2</policy> 
<description lang="en">last but two loudest room segment 
</description> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 


</mediaCapture> 

<mediaCapture 
xmlns:xsi-"https://www.w3.0rg/2001/XMLSchema- instance" 
xsi:type="videoCaptureType" captureID-"VC7" 
mediaType="video"> 


<captureSceneIDREF>CS1</captureSceneIDREF> 
<spatialInformation> 
<captureArea> 
<bottomLeft> 
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<x>-3.0</x> 
<y>20.0</y> 
<z>9.0</Z> 
</bottomLeft> 
<bottomRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>9.0</z> 
</bottomRight> 
<topLeft> 
<x>-3.0</x> 
<y>20.0</y> 
<z>11.0</Z> 
</topLeft> 
<topRight> 
«x23.0«/x» 
<y>20.0</y> 
<z>11.0</Z> 
</topRight> 
</captureArea> 
</spatialInformation> 
<content> 
<mediaCaptureIDREF>VC3</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC5</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC6</mediaCaptureIDREF> 
</content> 
<maxCaptures exactNumber="true">3</maxCaptures> 
<encGroupIDREF>EG@</encGroupIDREF> 
<description lang="en">big picture of the current 
speaker + pips about previous speakers</description> 
<priority>3</priority> 
<lang>it</lang> 
<mobility>static</mobility> 
<view>individual</view> 


</mediaCapture> 
</ns2:mediaCaptures> 
<ns2 :encodingGroups> 
«encodingGroup encodingGroupID="EG@"> 


<maxGroupBandwidth>600000</maxGroupBandwidth> 
<encodingIDList> 
<encodingID>ENC1</encodingID> 
<encodingID>ENC2</encodingID> 
<encodingID>ENC3</encodingID> 
</encodingIDList> 


</encodingGroup> 
<encodingGroup encodingGroupID="EG1"> 


<maxGroupBandwidth>300000</maxGroupBandwidth> 
<encodingIDList> 
<encodingID>ENC4</encodingID> 
<encodingID>ENC5</encodingID> 
</encodingIDList> 


</encodingGroup> 
</ns2:encodingGroups> 
<ns2 :captureScenes> 
<captureScene scale="unknown" sceneID="CS1"> 


<sceneViews> 
<sceneView sceneViewID="SE1"> 
<description lang="en">participants' individual 
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videos</description> 
«mediaCaptureIDs» 
<mediaCaptureIDREF>VC0</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC1</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC2</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE2"> 
<description lang="en">loudest segment of the 
room</description> 
«mediaCaptureIDs» 
<mediaCaptureIDREF>VC3</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE5"> 
<description lang="en">loudest segment of the 
room + pips</description> 
«mediaCaptureIDs» 
<mediaCaptureIDREF>VC7</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE4"> 
<description lang="en">room audio</description> 
«mediaCaptureIDs» 
<mediaCaptureIDREF>AC0</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
<sceneView sceneViewID="SE3"> 
<description lang="en">room video</description> 
<mediaCaptureIDs> 
<mediaCaptureIDREF>VC4</mediaCaptureIDREF> 
</mediaCaptureIDs> 
</sceneView> 
</sceneViews> 
</captureScene> 
</ns2:captureScenes> 
<ns2 :simultaneousSets> 
<simultaneousSet setID="SS1"> 
<mediaCaptureIDREF>VC3</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC7</mediaCaptureIDREF> 
<sceneViewIDREF>SE1</sceneViewIDREF> 
</simultaneousSet> 
<simultaneousSet setID="SS2"> 
<mediaCaptureIDREF>VC0</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC2</mediaCaptureIDREF> 
<mediaCaptureIDREF>VC4</mediaCaptureIDREF> 
</simultaneousSet> 
</ns2:simultaneousSets> 
«ns2 :people> 
<person personID="bob"> 
<personInfo> 
«ns3:fn» 
<ns3 :text>Bob</ns3 :text> 
</ns3:fn> 
</personInfo> 
<personType>minute taker</personType> 
</person> 
«person personID="alice"> 


Presta & Romano Experimental Page 53 


RFC 8847 CLUE 


<personInfo> 
<ns3:fn> 
<ns3 :text>Alice</ns3 :text> 
</ns3:fn> 
</personInfo> 
<personType>presenter</personType> 
</person> 
<person personID="ciccio"> 
<personInfo> 
<ns3 :fn> 
<ns3 :text>Ciccio</ns3:text> 
</ns3:fn> 
</personInfo> 
<personType>chairman</personType> 
<personType>timekeeper</personType> 
</person> 
</ns2:people> 
</ns2:advertisement> 


10.7. CLUE Message No. 7: 'ack' 


<?xml version="1.0" encoding-"UTF-8" standalone="yes"?> 
<ack xmlns="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE" v="2.7"> 
<clueId>CP2</clueId> 
<sequenceNr>23</sequenceNr> 
<responseCode>200</responseCode> 
<reasonString>Success</reasonString> 
<advSequenceNr>13</advSequenceNr> 
</ack> 
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10.8. CLUE Message No. 8: 'configure' 


<?xml version="1.0" encoding-"UTF-8" standalone="yes"?> 
<ns2:configure xmlns="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE” v="2.7"> 

<ns2:clueId>CP2</ns2:clueId> 

<ns2 :sequenceNr>24</ns2 :sequenceNr> 

<ns2 :advSequenceNr>13</ns2:advSequenceNr> 

«ns2:captureEncodings» 

«captureEncoding ID="ce123"> 
<captureID>AC0</captureID> 
<encodingID>ENC4</encodingID> 

</captureEncoding> 

<captureEncoding ID="ce456"> 
<captureID>VC7</captureID> 
<encodingID>ENC1</encodingID> 
<configuredContent> 

<sceneViewIDREF>SE5</sceneViewIDREF> 

</configuredContent> 

</captureEncoding> 

</ns2:captureEncodings> 
</ns2:configure> 


10.9. CLUE Message No. 9: 'configureResponse' 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<ns2:configureResponse xmlns="urn:ietf:params:xml:ns:clue-info" 
xmlns:ns2="urn:ietf:params:xml:ns:clue-protocol" 
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" 
xmlns:xsi="https://www.w3.0rg/2001/XMLSchema-instance" 
protocol="CLUE" v="2.7"> 
<ns2:clueId>CP1</ns2:clueId> 
<ns2 :sequenceNr>14</ns2 :sequenceNr> 
<ns2:responseCode>200</ns2:responseCode> 
<ns2:reasonString>Success</ns2:reasonString> 
<ns2 :confSequenceNr>24</ns2:confSequenceNr> 
</ns2:configureResponse> 


11. Security Considerations 


As a general consideration, we would like to point out that the CLUE framework (and related 
protocol) has been conceived from the outset by embracing the security-by-design paradigm. As a 
result, a number of requirements have been identified and properly standardized as mandatory 
within the entire set of documents associated with the CLUE architecture. Requirements include 
(i) the use of cryptography and authentication, (ii) protection of all sensitive fields, (iii) mutual 
authentication between CLUE endpoints, (iv) the presence of authorization mechanisms, and (v) 
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the presence of native defense mechanisms against malicious activities such as eavesdropping, 
selective modification, deletion, and replay (and related combinations thereof). Hence, security 
of the single components of the CLUE solution cannot be evaluated independently of the 
integrated view of the final architecture. 


The CLUE protocol is an application-level protocol allowing a Media Producer and an MC to 
negotiate a variegated set of parameters associated with the establishment of a telepresence 
session. This unavoidably exposes a CLUE-enabled telepresence system to a number of potential 
threats, most of which are extensively discussed in the CLUE framework document [RFC8845]. 
The Security Considerations section of [RFC8845] actually discusses issues associated with the 
setup and management of a telepresence session in both (1) the basic case involving two CLUE 
endpoints acting as the MP and the MC, respectively and (2) the more advanced scenario 
envisaging the presence of an MCU. 


The CLUE framework document [RFC8845] also mentions that the information carried within 
CLUE protocol messages might contain sensitive data, which SHOULD hence be accessed only by 
authenticated endpoints. Security issues associated with the CLUE data model schema are 
discussed in [RFC8846]. 


There is extra information carried by the CLUE protocol that is not associated with the CLUE data 
model schema and that exposes information that might be of concern. This information is 
primarily exchanged during the negotiation phase via the 'options' and 'optionsResponse' 
messages. In the CP state machine's OPTIONS state, both parties agree on the version and 
extensions to be used in the subsequent CLUE message exchange phase. A malicious participant 
might either (1) try to retrieve a detailed footprint of a specific CLUE protocol implementation 
during this initial setup phase or (2) force the communicating party to use a version of the 
protocol that is outdated and that they know how to break. Indeed, exposing all of the supported 
versions and extensions could conceivably leak information about the specific implementation of 
the protocol. In theory, an implementation could choose not to announce all of the versions it 
supports if it wants to avoid such leakage, although this would come at the expense of 
interoperability. With respect to the above considerations, it is noted that the OPTIONS state is 
only reached after the CLUE data channel has been successfully set up. This ensures that only 
authenticated parties can exchange 'options' messages and related 'optionsResponse' messages, 
and hence drastically reduces the attack surface that is exposed to malicious parties. 


The CLUE framework clearly states the requirement to protect CLUE protocol messages against 
threats deriving from the presence of a malicious agent capable of gaining access to the CLUE 
data channel. Such a requirement is met by the CLUE data channel solution described in 
[RFC8850], which ensures protection from both message recovery and message tampering. With 
respect to this last point, any implementation of the CLUE protocol compliant with the CLUE 
specification MUST rely on the exchange of messages that flow on top of a reliable and ordered 
SCTP-over-DTLS transport channel connecting two CPs. 
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12. IANA Considerations 


This document registers a new XML namespace, a new XML schema, and the media type for the 
schema. This document also registers the "CLUE" Application Service tag and the "CLUE" 
Application Protocol tag and defines registries for the CLUE messages and response codes. 


12.1. URN Sub-Namespace Registration 


This section registers a new XML namespace, urn:ietf :params:xml:ns:clue-protocol. 


URI: urn:ietf:params:xml:ns:clue-protocol 


Registrant Contact: IESG (iesg@ietf.org). 


XML: 


<CODE BEGINS> 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="https://www.w3.0rg/1999/xhtml" xml:lang="en"> 
<head> 
<title>CLUE Messages</title> 
</head> 
<body> 
<h1>Namespace for CLUE Messages</h1> 
<h2>urn:ietf:params:xml:ns:clue-protocol</h2> 
<p>See <a href="https://www.rfc-editor.org/rfc/rfc8847.txt"> 
RFC 8847</a>.</p> 
</body> 
</html> 


<CODE ENDS> 


12.2. XML Schema Registration 


This section registers an XML schema per the guidelines in [RFC3688]. 


URI: urn:ietf:params:xml:schema:clue-protocol 
Registrant Contact: IESG (iesg@ietf.org). 


Schema: The XML for this schema can be found in Section 9 of this document. 


12.3. Media Type Registration for "application/clue+xml" 


This section registers the application/clue+xml media type. 
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To: ietf-types@iana.org 

Subject: Registration of media type "application/clue+xml" 
Media type name: application 

Subtype name: clue+xml 

Required parameters: (none) 


Optional parameters: charset. Same as the charset parameter of "application/xml" as specified 
in [RFC7303], Section 4.2. 


Encoding considerations: Same as the encoding considerations of "application/gml" as specified 
in [RFC7303], Section 4.2. 


Security considerations: This content type is designed to carry protocol data related to 
telepresence session control. Some of the data could be considered private. This media type 
does not provide any protection; thus, other mechanisms, such as those described in Section 
11 of this document, are required to protect the data. This media type does not contain 
executable content. 


Interoperability considerations: None. 
Published specification: RFC 8847 
Applications that use this media type: CLUE Participants. 


Additional Information: 


Magic Number(s): (none) 
File extension(s): .xml 
Macintosh File Type Code(s): TEXT 


Person & email address to contact for further information: Simon Pietro Romano 
(spromano@unina. it). 


Intended usage: LIMITED USE 
Author/Change controller: The IETF 


Other information: This media type is a specialization of application/xml [RFC7303], and many 
of the considerations described there also apply to application/clue+xml. 


12.4. CLUE Protocol Registry 


Per this document, IANA has created new registries for CLUE messages and response codes. 


12.4.1. CLUE Message Types 


The following summarizes the registry for CLUE messages: 


Related Registry: CLUE Message Types 
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Defining RFC: RFC 8847 


Registration/Assignment Procedures: Following the policies outlined in [RFC8126], the IANA 
policy for assigning new values for the CLUE message types for the CLUE protocol is 
Specification Required. 


Registrant Contact: IESG (iesg@ietf.org). 


The initial table of CLUE messages is populated using the CLUE messages described in Section 5 
and defined in the XML schema in Section 9. 


Message Description Reference 


options Sent by the CI to the CR in the initiation phase to specify RFC 8847 
the roles played by the CI, the supported versions, and 
the supported extensions. 


optionsResponse Sent by the CI to the CR in reply to an 'options' message, RFC 8847 
to establish the version and extensions to be used in the 
subsequent exchange of CLUE messages. 


advertisement Sent by the MP to the MC to specify the telepresence RFC 8847 
capabilities of the MP expressed according to the CLUE 
framework. 

ack Sent by the MC to the MP to acknowledge the reception of RFC 8847 


an ‘advertisement’ message. 


configure Sent by the MC to the MP to specify the desired media RFC 8847 
captures among those specified in the 'advertisement'. 


configureResponse Sent by the MP to the MC in reply to a 'configure' message RFC 8847 
to communicate whether or not the configuration request 
has been successfully processed. 


Table 2: Initial IANA Table of CLUE Messages 


12.4.2. CLUE Response Codes 


The following summarizes the registry for CLUE response codes: 


Related Registry: CLUE Response Codes 
Defining RFC: RFC 8847 


Registration/Assignment Procedures: Following the policies outlined in [RFC8126], the IANA 
policy for assigning new values for the response codes for CLUE is Specification Required. 


Registrant Contact: IESG (iesg@ietf.org). 
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The initial table of CLUE response codes is populated using the response codes defined in Section 


5.7 as follows 


Number 


200 


300 


301 


302 


303 


400 


401 


402 


403 


404 


405 


Default Reason 
String 


Success 


Low-level 
request error 


Bad syntax 


Invalid value 


Conflicting 
values 


Semantic errors 


Version not 
supported 


Invalid 
sequencing 


Invalid identifier 


Advertisement 
expired 


Subset choice not 


allowed 


Description 


The request has been successfully processed. 


A generic low-level request error has occurred. 


The XML syntax of the message is not correct. 


The message contains an invalid parameter 
value. 


The message contains values that cannot be 
used together. 


The received CLUE protocol message contains 
semantic errors. 


The protocol version used in the message is not 
supported. 


The received message contains an unexpected 
sequence number (e.g., sequence number gap, 
repeated sequence number, or sequence 
number outdated). 


The clueld used in the message is invalid or 
unknown. 


The sequence number of the advertisement the 
‘configure’ message refers to is out of date. 


The subset choice is not allowed for the 
specified Multiple Content Capture. 


Table 3: Initial IANA Table of CLUE Response Codes 
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